Dec 95 How-To Columns

Build Custom Desktops For Network Users

by: Eric Carr

DOES CHAOS RULE your networked desktops? Do you have users with varying levels of experience trying to learn Windows 95? Do folks insist they don't have this capability or that function, when you know you installed it on their machines just last week? Would you like a standard desktop environment for most, if not all, of your users?

Most network administrators I know would answer "yes" to these questions. Contemporary graphical user interfaces--Win95 included--present so many customization choices that some people get lost just setting up their machines. Fortunately, Win95 has some powerful features to help control chaos on the networked desktop by bringing order to the client. Implemented prudently, these features will make your life a lot easier.

You'll find a rich set of controls and stored machine configurations in Win95's Registry. This database of system settings is modified as you create and change your Windows environment. If you haven't used the Registry, don't worry. Many of the settings are made without your knowledge. The Registry is composed of two files: USER.DAT and SYSTEM.DAT. We're interested in USER.DAT, the file in which user settings are stored. (SYSTEM.DAT contains computer-specific settings, but that's fodder for another column.)

Hold that thought about storing all of a user's preferences (Control Panel settings, user interface preferences, font selection, background, colors and so on) in one file. For now, consider that Win95 natively allows different users to maintain their own preferences on the same machine. It does this by maintaining multiple, personalized copies of preferences (one for each user) in a hierarchical tree. These preferences, called user profiles, are a clever solution to a problem that's been nagging Windows users for a long time: They allow multiple individuals to customize the interface to their liking without interfering with the current settings. After all, some users don't like viewing fluorescent green windows on a pink background, with squawks, beeps and gongs sounding whenever they make a mistake. And some users shouldn't be playing around with virtual memory settings. Why not key the settings to the individual?

That's great if you share a machine with others. But what if you have to move around the enterprise? Wouldn't you like to take this functionality with you? Well, you can. When you enable User Profiles, select an appropriate 32-bit primary network log-on client (check the properties of the client you're using to be sure) and set up the user in the normal way. Win95 automatically stores the user profile on the server. When the user performs a normal log-off, the current USER.DAT and (if enabled) folders are copied to the server. Upon log-in, the profile is copied into the local machine's Registry. If you're using NetWare, the profile is placed in the user's SYS: MAIL\USERID directory. On a Windows NT server, the settings are stored in the user's defined home directory. If you don't use NT or NetWare, or don't use 32-bit clients, don't despair. You can still take your user profile with you--it just requires a little more effort. The table "The What, Where and How of Roving User Policies" shows what has to happen where. To exert a little more control over all those Win95 desktops that keep popping up all over the place, consider deploying a Mandatory User Profile, a modified version of the User Profile. This variant is enforced at every log-in and is user-specific. Any changes made during the session are not replicated on the server. So in effect, the same settings come up after log-on every time. The only catch is this: Mandatory User Profiles work only with NetWare and Windows NT servers.

To create mandatory profiles, set up the USER.DAT file with the settings you want, and copy this file as USER.MAN to the network directory of each user for whom you wish to apply the settings. If icons, Start menu programs and the like are part of the profile, copy those to the network directory as well. When the user logs on, and Win95 sees USER.MAN in the user's network directory, it will load those settings into the Registry. Upon log-off, the Registry settings in USER.DAT on the local machine aren't copied back to the network. In essence, the same settings are loaded every time. This is a great way to control (and help) users who've gotten lost in Win95. At the very worst, they can shut down, reboot and log on again. Things will always be the same.

Although they're a workable solution, these user profiles and mandatory user profiles attack only half the issue of enterprise management of the desktop--the user-configurable aspects. I haven't discussed the active management of what a user can (and can't) do on the desktop. Nor have I discussed how to limit what a user can configure on the desktop. I haven't told you how to change several or several thousand copies of the Registry on an equal number of computers. It's unlikely that everyone in your organization can use the same desktop with the same capabilities. You can probably categorize users into groups, each with its own set of information processing needs, tools and abilities. Wouldn't it be easier if you could give users the tools they need by group?

These additional functions are available to the ever-vigilant network administrator at the next level of chaos (I mean, networked desktop) management, and are known as System Policies. I'll get to them in a future column.

Don't use a 32-bit client?

Don't run NT or NetWare? Don't worry.

Find Salvation from E-Mail and Backup Hell

by: John D. Ruley

In the meantime, MS Mail 3.2 Remote--which I've always considered to be clumsy, but reliable--was becoming almost unusable. I'm not sure how much of the problem was due to my huge .MMF file and how much was due to noisy phone lines. I did know I was missing critical information sent by other staff members. It was time for a change.

Fortunately, I had something to change to: Beta 4 of Microsoft's Exchange e-mail client for Windows NT. Instead of using Mail Remote's unreliable modem protocol, Exchange uses a remote network connection provided by NT's built-in Remote Access Service (RAS). So far, it's been completely reliable.

Using beta software for day-to-day business is always risky, but I didn't have much choice. Other Exchange beta users warned me about its one-time, one-way conversion of .MMF files to the new .PST format. To preserve the ability to revert to Mail Remote if Exchange didn't work, I compressed the hard disk on one of my file servers--freeing up a couple hundred megabytes of disk space--and moved my .MMF file to the server.

So far so good. (Backing the .MMF file to tape would have been better--if I had the tape.) But the next thing I did was stupid. One of Mail Remote's many endearing features is it doesn't reduce the .MMF file when you delete messages. Although it marks the messages deleted, it doesn't physically release the disk space. To compact the file, you have to run the Mail client in a special maintenance mode. This creates a completely new mail file that doesn't contain the deleted data. Because I had the .MMF file on a compressed hard disk with plenty of space, I figured this would be a good time to compact it. So I fired up NT's built-in mail client. I had never set it up, so I went through the installation procedure and typed in JRULEY.MMF when it asked for the name of the .MMF file. I was appalled when the client opened and showed no messages. In stark terror, I opened a command prompt and found that JRULEY.MMF was now a 24KB file--completely empty. NT's Mail client had overwritten my message file.

That was bad. Even worse, it happened on a compressed NTFS partition. Had it happened on a DOS-compatible FAT partition, I might have been able to shut down NT, dual-boot DOS (or Win95) and undelete the old message file. The only file recovery tool for NTFS is my own Disk Editor (available as WinMag NT Disk Tools Beta 1 from the download sites on the Windows Online page in this issue), and it can't deal with compressed files. At a recent NT Server Professional Developer's Conference, one of NT's creators responded to a question about encrypting files on NT by saying, "Use compression. That'll scramble it!" He wasn't kidding. Using my Disk Editor, I found part of the message file, but it was compressed and largely unreadable.

Had I copied the file from its original location on my portable instead of just moving it, the original would have been intact. No such luck. So, for lack of a $50 tape cartridge, all 73MB of my stored e-mail messages are gone.

As my MS Mail 3.2 message file was headed for the great bit-bucket in the sky, I'd completed installation of the Exchange client. From the start, it worked much better. That's not to say it's perfect. I locked it up during the first hour when I tried to use the Find function while I was offline, and finding a reasonable way to use it remotely took some doing. But what a difference in reliability!

With MS Mail 3.2 Remote Client, I was lucky to transfer 15KB from our mail server during a typical daytime connection. One coworker messaged (on another mail system) that most messages he tried to send me were returned marked undeliverable. In my first two days using Exchange, I've had no mail failures.

My major gripe with the Exchange beta is it's not well integrated with RAS. When you try to set up Exchange without a live RAS connection, it offers you a Windows 95-style Dial-Up Networking option, but it won't dial in for you. Evidently, some of the necessary plumbing is still missing. Worse, although you can use the client to read your mail offline, it won't permit you to reply to messages. Attempting to do so generates a Mail Failure. The best way to use the client remotely is to log in with RAS, get your mail, read and reply to messages while you're online and then log off. To automate the process, I wrote these two batch files:

CONNECT.CMD:
rasdial winmagpdc jruleynt *

/domain: WIN_LAB
start rasmon
net use m: \\win1\mail\msmail\
maildata /user: jruley *
net use s: \\win1\data\share
net use u: \\win1\data\users\
jruley

This exploits NT's undocumented RASDIAL command-line function to log into WinMag's server using the same name I have listed in the RAS Phone Book. I have to specify the WIN_LAB domain and jruleynt user name because these aren't what I use in my office. The asterisk causes the batch file to prompt me for a password. Once RASDIAL completes, I start the Remote Access Monitor (RASMON), and then establish connections to the mail server and to shared network files I may want to use. From this point on, I just act as if I were logged into the network locally until I'm ready to log off. Then I execute a second batch file:

DISCONNECT.CMD:

rasdial winmagpdc /disconnect
net use m: /delete
net use s: /delete
net use u: /delete

DISCONNECT.CMD uses the RASDIAL command's /disconnect feature to close out the connection, then deletes the network connections, because they're CSNW connections to a NetWare server and have to be explicitly reestablished on each login.

With these two batch files to simplify the process, the Exchange beta client is a completely usable and far more reliable replacement for Mail 3.2 Remote. I wish I could tell you when Exchange will ship, but Microsoft's still saying "when it's ready." In the meantime, you might want to look into an MSDN Level II subscription. This gives you access to beta software, including the Exchange client I'm using. Again, using beta for your daily work is risky, but you may find you have no choice.

Speaking of RISC-y propositions ... Portability to RISC architectures has been one of NT's selling points since its introduction. Having had a RISC machine on my own desk for the past two years, I've been curious to see just how RISC-based platforms would fare in the NT marketplace.

After careful study of the NT-RISC market, I can sum it up in two words: It stinks. I reported the first half of the study last month in WinMag's NewsTrends section. Tracking downloads of platform-dependent files on CompuServe, I found three examples consistently showing Intel files being downloaded by more than 90 percent of downloaders. I also found that, of the RISC platforms, Digital's Alpha was by far the most popular, with about 4 percent of downloads for the most recent file.

That turned out to be an optimistic assessment. If you have a CompuServe account you can check this yourself. Look in the Shell Technology Preview section. As I write this, several thousand people have downloaded the Intel version of the shell preview, but only a few hundred have downloaded any RISC version. Although the Alpha still seems to be the most popular RISC version, its downloads amount to barely 2 percent of the total. Why so little? In part, because very few RISC machines have been shipped. A recent Digital press release proudly announced the shipment of its 100,000th Alpha-based system. Assuming NT's installed base is more than a million (I'd guess it's more than 2 million), there's no way the Alpha could account for more than 5 to 10 percent of the NT installed base. Digital supports UNIX and VMS on Alpha as well as NT. And a source tells me that although NT is the fastest-growing operating system on Alpha, it's been shipped with only 20 percent of Alphas so far--just 1 to 2 percent of NT's installed base.

The other side of the coin became apparent when I reviewed application availability for NT on Microsoft's new InfoSource CD (800-426-9400). It lists more than 4,000 NT and Back Office-compatible applications, and it's free. It has a search engine that lets you specify applications for a specific platform. Practically all application vendors suport Intel, but only about 30 percent support Alpha. Even fewer support Mips or PowerPC.

This is a classic chicken-and-egg problem. Users want applications; application vendors want customers. Each waits for the other, and not much happens. NT had the same problem during its first couple of years.

Be very careful before buying a RISC-based system for NT. Get InfoSource and make sure the software you want is compatible with the platform. RISC has its place. Digital has done an exceptional job lining up high-end CAD and engineering vendors to support its latest Alpha-based systems. These are twice as fast as comparable Intel-based systems, but unless you know exactly what you're buying, RISC is a good way to lose your shirt.

Several folks have written to complain that Executive Software's Diskeeper defragmenter for NT--which I highlighted in my August column--doesn't work with NT 3.51. That's because Diskeeper hooks the NT kernel directly, so whenever Microsoft updates the kernel, Executive Software has to update Diskeeper. Executive Software gets a complete copy of the NT source code--all 5 million lines of it--and has to find any changes that affect its software. The company has done so, and you can download a free update from its Web site: http: //www.earthlink.net/execsoft, or from CompuServe (GO: EXECUSOFT, "executive software" library).

This month's brilliant idea is Microsoft's decision to update the Windows 95-style shell technology preview and include NT 3.51 Service Pack 1 with the updated files. Originally, Microsoft said it wouldn't update the preview--preferring to put development effort into getting out the next full NT beta with the new shell integrated. Apparently, user demand and complaints about problems running certain applications--including Microsoft's own Office for Windows 95--changed the picture. Because the update came out about the same time as Service Pack 1, which contains its own set of bug fixes, both were rolled up together. You can download the update from CompuServe's MSDR forum or from the BUSSYS/WINNT-UNSUP-ED section of ftp.microsoft. com.

Bogus ideas are as close as your Web browser. As of this writing, I still don't have direct Internet access from my home in Modesto (I will by the time you read this), and I've been spending a lot of time in America Online's Web interface. AOL's Web browser is awful. But what really annoys me are Web sites that require Netscape, or worse, provide no text pointers. A certain server vendor ought to clean up its site or remove it. The company should check out the http: //arnica.csustan.edu Web site, maintained by Dr. Steven Wolf and friends from California State University. The site, called Stanislaus, features a section on Web-page design that ought to be required reading for all Web-based information vendors. Incidently, the CSU-Stanislaus site, like many newer Web sites, is NT-hosted.

Maze Lords Bitmaps Make Learning Fun

by: Martin Heller

After a brief silence broken only by the rattle of coffee cups and the clicking of mice: "This is interesting. The viewing logic traverses a three-dimensional array and picks out the visible walls. It constructs a list of PT_MOVETO and PT_LINETO drawing instructions, which are eventually passed to a single call to the PolyDraw function. No wonder it's so snappy."
"How are the drones and other players drawn?" I queried. "You can see they're bitmaps. Why don't they obscure the maze?"

After a long pause came the puzzled reply: "Uh ... the DrawPlayers function constructs some sort of bounding rectangle, and then posts an IDM_REDRAW message. Oh! This is complicated. The IDM_REDRAW handler either redraws the maze in the bounding rectangle or blits into the bounding rectangle. The routine it calls to draw the maze is the one we were just looking at, and it keeps track of which players and drones are visible. Then it calls DrawFoundPlayers, which constructs a bounding rectangle for each player or drone and calls DrawClippedPic to blit the image, I guess."

"DrawClippedPic does an awful lot of work. What is all this stuff with the pic and the mask? Why does it have to use two calls to BitBlt or StretchBlt? Take a look at the raster operation (ROP) codes. Remember the ROP code for the block transfer operation; the last parameter in BitBlt and StretchBlt? What is it?"

By now, the whole class was involved: "The first BitBlt call does a SRCAND into the screen DC from the mask DC. The second one does a SRCPAINT into the screen DC from the pic DC. Why two?"

"It'll help if you look at the bitmaps and look up the meaning of the ROP codes," I told them. "Notice the image--the `pic'--has a black background, but the mask has a white background and a black foreground. The first call uses the mask with SRCAND, which combines the source and destination colors with a Boolean AND operation. In other words, it leaves the white area--the background--alone and blacks out the foreground, the area where the figure will be drawn.

"The second call uses the picture with SRCPAINT, which combines the source and destination colors with a Boolean OR operation. In other words, the background is again left alone, and the figure is painted into an area we know is empty. Obviously, the code is intended to work in both Win16 and Win32 targets. Otherwise, the two BitBlt operations could have been combined into a single MaskBlt operation using a SRCCOPY ROP code for the figure and a SRCPAINT operation for the background."

We continued our study of this sample after a lecture on debugging. We found if you stopped playing the game to look something up, it would crash with an Unable to Create MailSlot message. Eventually, we cured the problem with a two-line patch. I don't want to ruin your fun--or my next class--so I won't publish it here. I'm literally leaving it as a student exercise.

My class was confused when I started explaining all the ways to display bitmaps efficiently. It used to be a difficult area because there were no good, fast ways to get device-independent bitmaps (DIBs) from disk to screen. Now it's muddled by too many choices--and not all of them are supported on all systems at all color depths. It's also an important area for applications, tutorials and games that want to display or animate images efficiently.

All Windows platforms support StretchDIBits, but it can sometimes be slow. The worst case I've found is when it displays a 24-bit image using an 8-bit display driver on Windows 3.x. The best scenario is when it shows an 8-bit image using an 8-bit display driver on Windows 95. Lots of old code uses StretchDIBits, so it's good that Microsoft put some work into the implementation in the Windows 95 display drivers. SetDIBitsToDevice is the no-stretch case of StretchDIBits. They have similar characteristics and share a great deal of code.

CreateDIBSection is a more efficient way to deal with DIBs than StretchDIBits. You call CreateDIBSection to make a DIB that your applications can write to directly. It's supported in Windows NT 3.5 and later, and in Windows 95. CreateDIBSection returns a bitmap handle, which you can select into a memory device context. You can then blit from the memory device context to the screen us-

ing BitBlt or StretchBlt, both of which are very fast.

For efficient DIB display on all Windows systems, consider using WinG. This implements the 8-bit functionality of Create DIBSection in its 16-bit version and calls CreateDIBSection in its 32-bit version. To use WinG, first call WinGCreateDC, WinGCreateBitmap and WinGSetDIBColorTable. When your off-screen image is ready, call WinGBitBlt to put it on the screen.

WinToon, a set of VFW extensions for frame animation, uses WinG to handle its off-screen buffering and image composition. It tracks each frame's invalid rectangles and updates the screen more efficiently than VFW, especially at key frames. VFW handles the audio synchronization. In other words, WinToon can combine captured video with computer-generated images to create spiffy--even interactive--frame animation.

So, the old standard device-independent bitmap APIs are too slow for games; CreateDIBSection helps, but it isn't portable. WinG gives you the capabilities of CreateDIBSection in a more portable way. VFW helps to create and play movies, and WinToon allows you to combine WinG and VFW for frame animation.

From a game programmer's point of view, that's fine, but it's not good enough for real work. Windows GDI's essential feature is its device independence; WinG, VFW and WinToon just build on that device-independent core. To write serious action games you need direct access to the video hardware--direct access to the sound and input hardware wouldn't hurt, either.

Enter the Windows 95 Games SDK (GDK for short). DirectDraw, the GDK's display component, allows direct manipulation of video display memory, hardware blitters, hardware overlays and page flipping. Other components let you manipulate the hardware directly for waveform and MIDI audio streaming, waveform mixing, interaction over the network and joystick input.

DirectDraw and the rest of the GDK conform to Microsoft's Component Object Model (COM). What does the documentation have to say about COM? "This is Microsoft's system object model. It has nothing to do with Object Linking and Embedding (OLE) 2.0." Okay, that helps.

Last month I explained that COM objects need to implement AddRef, QueryInterface and Release methods in their IUnknown classes. These member functions allow for later expansion. The DirectDraw specification has two API (nonmember) functions: DirectDrawCreate instantiates a DirectDraw object that represents a specific piece of display hardware and DirectDrawEnumerate obtains a list of all DirectDraw objects installed on a system.